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REMARKS 

Claim 26 has been amended. Claims 1-32 are pending. 
The specification has been amended to correct the infomialities noted in 
the Office Action. 

The parenthetical statements above several of the claims have been 
removed. Also, claim 26 has been amended to depend from claim 18. 

In the Office Action, claims 1,17 and 30-31 are rejected under 35 U.S.C. § 
102 as being anticipated by Rangarajan, US 6,275,225. This rejection is 
respectfully traversed. 

Claim 1 recites 1 a method for displaying managed object data associated 
with managed resources which includes (1) receiving at least one managed 
object selection and a task selection to apply to the at least one managed object 
selection, and (2) identifying at least one view definition corresponding to the task 
selection that defines a view with which to display managed object data related to 
the at least one managed object selection. A view corresponding to the view 
definition is displayed on a graphical user interface of a computer system, and 
managed object data related to the managed object selection is displayed within 
the view. 

As described in the present application, the above method provides 
flexibility in creating new or modified views for managed object data as new 
managed objects and/or tasks are added to a system even after the resource 
management application has been deployed. The flexibility stems in part from 
the association of view definitions with both tasks and managed objects. That is, 
a view definition is identified based upon the selection of a particular task to be 
applied to a particular object. This feature enables a user to view managed 
object data in different ways depending on the task that is being applied. 
Examples of types of tasks include systems management, configuration or 
monitoring operations. In one embodiment, the association of tasks and objects 
with views is made via a data dictionary as depicted in Figure 4. 
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Rangarajan shows a system that constructs user-configurable graphical 
user interfaces (GUIs), with application to the field of network management. A 
"wizard" is used to elicit a user's input regarding various aspects of the contents 
of a GUI, including topology infonnation and alamn infomiation. The resulting 
GUI or "configuration", an example of which is shown in Figure 9, has various 
panes where the desired infonnation is shown, and includes "selectable control 
areas" or SCAs that can be activated to invoke certain operations. In the GUI of 
Figure 9, for example, an SCA 909 can be activated to obtain "device detail" 
infomiation. 

In Rangarajan, a distinction must be drawn between the process of 
creating configurations and the process, such as a network management 
console, that utilizes the configurations that have been created. Most of the 
disclosure of Rangarajan is focused on the former, i.e., the processes by which 
configurations are created. The end result of these processes is a set of 
configurations that can be used in a process such as a network management 
console. The sole example given of the use of a configuration is in Figure 9. 
This distinction is made to highlight an important shortcoming of Rangarajan as it 
pertains to the present application - in Rangarajan, there is no choosing of a 
configuration based on a task selected to be performed on a selected object. In 
Rangarajan, a configuration is chosen in the context of a "profile manager" 
depicted in Figures 7 and 8, which is entirely separate from any process of 
selecting tasks to be performed on managed objects. It will be observed that 
there is no facility within the profile manager that enables a user to perform 
management functions on managed objects - the selection of configurations is 
done solely in response to user input explicitly specifying which configuration to 
use, without reference to any user-selected task an any managed objects. 
Similarly, the network management console depicted in Figure 9 has no linkage 
back to the profile manager such that a configuration can be chosen on the basis 
of a user's selection of a task and a managed object - the console simply uses 
the configuration that has been pre-selected by the user via the profile manager. 
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It is noted that column 9 of Rangarajan, which is referred to in the Office 
Action, is seen to describe the use of the profile manager, which is summarized 
above. Thus, contrary to the assertion in the Office Action, this section of 
Rangarajan is not seen to teach identifying a view definition corresponding to a 
received task selection and a received managed object selection. Rather, this 
section describes only the creation, management and selection of configurations 
by a user in an explicit, menu-driven process apart from any network 
management operations. 

It is respectfully submitted that Rangarajan does not anticipate claim 1, 
because it fails to teach all the elements thereof. Specifically, Rangarajan fails to 
teach (1) receiving at least one managed object selection and a task selection to 
apply to the at least one managed object selection, and (2) identifying at least 
one view definition corresponding to the task selection that defines a view with 
which to display managed object data related to the at least one managed object 
selection. As described above, Rangarajan discloses that configurations are 
explicitly selected by a user in the context of a "profile manager", entirely 
separate from any process of selecting tasks to be performed on managed 
objects. There is no method or data structure disclosed within Rangarajan that 
associates a user-selected task with a view definition, such that managed object 
information from the execution of the task is displayed in accordance with the 
corresponding view. In Rangarajan, information is displayed only in accordance 
with a configuration that is explicitly chosen by the user (via the profile manager) 
in advance of any console operation executed from the configuration screen. 
Accordingly, Rangarajan is not seen to teach these elements of claim 1 , and 
therefore cannot anticipate claim 1 under 35 U.S.C. § 102. 

Claims 17, 30 and 31 recite, either directly or indirectly, the above- 
discussed features of claim 1 , and therefore the above remarks with respect to 
the applicability of Rangarajan are likewise applicable to these claims. 
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In the Office Action, claims 14-16 are rejected under 35 U.S.C. § 102 as 
being anticipated by Besaw, US 20020198973. This rejection is respectfully 
traversed. 

Claim 14 recites a server-executed method of providing access to 
managed object data that includes parsing a view definitions document, an object 
definitions document and an object data document to create a data dictionary 
that contains a master view definition, task definitions, view definitions and 
managed object data definitions, and that further defines, for each task definition, 
a use case that defines a mapping of a view definition to a portion of a managed 
object data definition. The method further detects an initiation of a resource 
management process, and passes the data dictionary to the resource 
management process to allow the resource management process to process the 
data dictionary. 

As described in the present application, this technique also provides for 
flexibility in creating, modifying, and deploying new views in a system such as a 
resource management system, and does so while enabling the resource 
management process to be relatively "lightweight", i.e., not requiring predefined 
or hard-coded knowledge of all resources and all views that might be needed at 
all times. A developer of a managed resource simply needs to create task, 
object and view definitions for the resource. These can be incorporated into view 
definition and object definition documents, which are in turn utilized by the server 
to create the data dictionary used by the resource management process to 
access the management functionality specified thereby. 

Besaw discloses a system having a "management information portal" or 
MIP 134 via which a browser-based client can obtain network infomiation. 
Included in the MIP are a module library 205, a filter library 207, and a user 
configuration database 209. The user configuration database 209 specifies, on a 
per-customer basis, which modules and filters are to be utilized in obtaining and 
presenting network information to the customer. As shown in Figure 7, the MIP 
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parses the user configuration database to identify and apply user-specific 
security and display filters in generating results to be displayed to the user. 

Paragraphs 26-30, 46 and 49 of Besaw, which are referred to in the Office 
Action, refer to specific aspects of "customized management services" provided 
to a customer or user, including the above-described functionality of the user 
configuration database 209. As stated in paragraph 31 , an edit manager (EM) 
304 allows a service provider to edit a customer configuration file that may be a 
record, text file, etc. and is stored in the user configuration database 209. Each 
configuration record contains customer-specific information such as display 
preferences and security filter definitions. Paragraph 49 mentions that the 
configuration record is parsed to detennine which modules from the module 
library are applicable to the customer. Paragraphs 42-46 describe examples of 
security and display filters that are invoked when a customer logs into the MIP 
134, resulting in the creation of subsets of nodes for which infomriation is to be 
displayed. These filters are specified in XML. 

There does not appear to be any dictionary-like item in Besaw that is 
created from any definition-like document. The security and display filters appear 
to be created by a text editor or other tool that can generate XML code, and not 
algorithmically based on the contents of any separate definition-like documents. 
The creation of the user configuration file does not seem to be specified at all, 
and certainly is not described as being generated based on the contents of 
separate definition-like documents. Thus, notwithstanding these portions 
referred to in the Office Action, Besaw is not seen to teach any dictionary-like 
item that is created from any definition-like documents. 

It is respectfully urged that Besaw does not anticipate claim 14, because it 
fails to teach all the elements thereof. Specifically, Besaw is not seen to teach 
parsing a view definitions document, an object definitions document and an 
object data document to create a data dictionary that contains a master view 
definition, task definitions, view definitions and managed object data definitions, 
and that further defines, for each task definition, a use case that defines a 
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mapping of a view definition to a portion of a managed object data definition. 
Besaw shows only the use of filters and a user configuration file that specifies 
which filters are to be utilized in displaying information to the user. None of these 
items is created from a set of definition-like documents. Additionally, none of 
these items includes a master view definition, task definitions, view definitions 
and managed object data definitions, and further defines, for each task definition, 
a use case that defines a mapping of a view definition to a portion of a managed 
object data definition. Rather, in Besaw each filter is specific to its domain, i.e., 
security or display, and does not contain the multi-faceted collection of data in a 
data dictionary as recited in claim 14. Also, the user configuration file of Besaw 
merely specifies which of the modules to employ, and is not seen to include at 
least a master view definition, task definitions, and managed object data 
definitions, nor a use case that defines a mapping of a view definition to a portion 
of a managed object data definition. As no other items in Besaw seem to be 
relevant, it appears that these elements of claim 1 are absent from Besaw, and 
therefore Besaw cannot anticipate claim 1 under 35 U.S.C. § 102. 

Claims 15-16 are dependent from claim 14, and therefore the above 
remarks with respect to the applicability of Besaw are likewise applicable to these 
claims. 

In the Office Action, claims 2-13, 18-29 and 32 are rejected under 35 
U.S.C. § 103 as being obvious in view of Rangarajan and Besaw. This rejection 
is respectfully traversed. 

This rejection is founded primarily on a combination of selected portions of 
Rangarajan and Besaw which have been individually applied to other claims (e.g. 
claims 1 and 14 as described above). Inasmuch as these references fail to teach 
all the elements of the above-discussed claims individually, they likewise fail to 
teach all the elements of claims 2-13, 18-29 and 32 which at least in part are 
combinations of the above-discussed claims. For at least these reasons, then, 
these references cannot render claims 2-13, 18-29 and 32 obvious, because they 
fail to teach all the elements thereof. 
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Addltionally, it appears that in many cases the specific language of claims 
2-13, 18-29 and 32 is being ignored in the assertions with respect to Besaw. 
Many statements in the Office Action appear conclusory and refer only very 
generally to paragraphs of Besaw, with no explanation of how all the specific 
claim limitations are found within the paragraphs. With respect to claim 2 for 
example, Besaw is not seen to teach a data dictionary as set forth in the claim, 
and in fact the Office Action offers no explanation at all of how this claimed 
subject matter is to be found in Besaw. The Office Action merely refers to 
paragraph 27 of Besaw in a conclusory manner. However, this paragraph 
describes only the existence of a database of the types of services available to 
customers, and does not describe anything that can be characterized as a 
"master view", for example, that is displayed on a GUI to enable a user to provide 
a task selection and a managed object selection. Without such a master view, 
Besaw cannot show the claimed data dictionary, which contains the master view. 
Likewise with respect to the subject matter of claims 3 and 19 - paragraph 27 of 
Besaw in no way describes a use case that is associated with a task definition 
and an object selection and that identifies a view definition in which data 
pertaining to the object and the task is displayed, and the Office Action In fact 
does not make any such specific allegation. Thus, these claims are seen to 
recite additional features that are also missing from Rangarajan and Besaw, and 
therefore are not rendered obvious thereby. 

In view of the foregoing, it is respectfully submitted that this application 
complies with all statutory requirements and Is therefore allowable. Favorable 
action is respectfully requested. The Examiner Is urged to telephone the 
undersigned attorney to resolve any issues that might be remaining after this 
amendment. 

If the U.S. Patent and Trademark Office deems a fee necessary, this fee 
may be charged to the account of the undersigned, Deposit Account No. 50- 
0901. 
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If the enclosed papers or fees are considered incomplete, the Patent 
Office is respectfully requested to contact the undersigned collect at (508) 366- 
9600, in Westborough, Massachusetts. 

Respectfully submitted, 
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